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ABSTRACT 


This  thesis  provides  a  critical  analysis  of  the  Navy’s 
Message  Processing  and  Distribution  System  (MPDS)  develop¬ 
ment.  A  historical  approach  is  used  in  presenting  the 
system’s  life  cycle  development  beginning  with  the  planning 
phase  and  ending  with  the  integrated  logistic  support  phase. 
Several  maintenance  problems  which  occurred  after  the  system 
was  accepted  for  Fleet  use  ware  examined  to  determine  if 
they  resulted  from  errors  in  the  acquisition  process.  The 
underlying  intent  of  the  thesis  is  to  use  the  MPDS  to  exa¬ 
mine  the  critical  decision  points  of  the  acquisition  process 
and  offer  constructive  recommendations  for  avoiding  the 
problems  which  hindered  the  successful  development  of  this 
system . 
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The  purpose  of  this  thesis  is  to  analyze  the  pertinent 
aspects  of  development  and  life  cycle  support  of  the  Navy's 
Automated  Message  Processing  and  Distribution  System  (MPDS) . 
The  historical  section  will  discuss  the  imperative  need  to 
automate  the  Navy’s  communication  systems.  It  will  then 
explain  the  Navy’s  decision  to  begin  developmental  effort  to 
automate  many  of  the  manual  communications  functions. 

The  development  of  the  MPDS  will  next  be  discussed  with 
detailed  emphasis  placed  on  the  following  topics: 

1.  Hardware  Specif ications 

2.  Software  Specifications 

3.  Security  Requirements 

4.  Configuration  Control 

5.  Testing  Procedures 

Next,  a  few  unique  problems  with  system  maintenance,  logis¬ 
tic  support,  and  training  will  also  be  examined. 

Finally,  cause/effact  conclusions  will  be  drawn  and 
coupled  with  constructive  recommendations  for  future  major 
system  development  projects. 


II.  PROJECT  HISTORY 

4.  BASELINE  II  COMMUNICATIONS  STUD! 

In  October  of  1966,  the  Commander  of  the  First  Fleet  con¬ 
ducted  a  Communications  Readiness  Exercise  to  determine  the 
Fleet’s  ability  to  handle  large  volumes  of  message  traffic 
during  simulated  wartime  conditions.  This  exercise  was 
known  as  Baseline  II,  and  it  revealed  the  fleet  was  unable 
to  handle  large  message  volumes  without  encountering  signi¬ 
ficant  delays.  These  delays  usually  occurred  in  areas  where 
humans  were  required  to  manually  handle  or  process  the  mes¬ 
sages.  Two  of  the  areas  where  major  delays  frequently 
occurred  were  identified  as  the  Naval  communication  Stations 
(NAVCOMSTAS)  and  Radio  Central  on  board  the  naval  ships. 

The  Naval  Electronics  Laboratory  Center  (NELC)  in  San 
Diego  was  directed  to  develop  a  system  which  would  reduce 
the  shipboard  delays  in  message  processing  and  distribution. 
The  objective  was  to  automate  as  many  manual  functions  as 
possible.  NELC  installed  the  firs’-  experimental  shipboard 
Massage  Processing  Distribution  system  (MPDS)  aboard  the  USS 
Oklahoma  City  (CG-5) .  This  initial  system  was  quite  small 
and  consisted  of  a  single  processor,  magnetic  disk  storage 
device,  and  a  high  speed  printer.  Many  updates  and  enhance¬ 
ments  were  added  to  this  system  as  they  became  available. 
Several  remote  printers  were  later  installed  at  important 
locations  throughout  the  ship,  but  no  attempt  was  made  to 
add  remote  interactive  terminals  (Ref.  1)  Consequently,  all 
outgoing  message  traffic  had  to  bs  physically  deposited  at 
Radio  Central  for  transmission  from  the  ship. 

B.  CVN-68  MESSAGE  PROCESSING  AND  DISTRIBUTION  SYSTEM 

At  the  same  time  that  NELC  was  working  on  the  CG-5  MPDS, 
it  began  work  on  the  fully  automated  MPDS  destined  for  ins¬ 
tallation  on  the  (JSS  Nimitz  (CVN-68)  .  This  system  was  to  be 
part  of  the  ship’s  original  equipment,  so  it  was  extremely 
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important  that  the  project's  completion  date  correspond 
closely  to  the  completion  of  construction  of  the  Nimitz.  Had 
MPDS  not  been  ready  and  available  on  time,  the  Nimitz  would 
have  been  forced  to  go  to  flea  with  an  extremely  degraded 
manual  communications  system.  Consequently,  proper  manage¬ 
ment  of  the  system's  development  by  NELC  was  of  immense 
importance  if  the  Navy's  readiness  objectives  were  to  be 
obtained. 

The  Nimitz  was  originally  scheduled  to  come  out  of  con¬ 
struction  in  late  1973,  but  reactor  delivery  slippage  caused 
several  delays  which  resulted  in  a  late  commissioning  in 
1975.  Since  the  MPDS  was  behind  schedule,  the  delivery  date 
slippage  for  the  reactors  gave  NELC  and  Planning  Research 
Company  (PRC)  badly  needed  additional  time  to  correct  sev¬ 
eral  software  problems  and  install  the  completed  system 
onboard  the  Nimitz  in  1974  without  causing  any  further 
delays.  ‘.Ref. 2] 

NELC  used  the  old  aircraft  carrier,  USS  Bunker  Hill,  to 
test  the  operation  of  MPDS  in  a  shipboard  environment  [Ref. 
3].  This  procedure  provided  NELC  with  the  opportunity  to 
examine  the  effects  of  the  shipboard  electricity,  excess 
humidity,  and  metallic  influence  upon  the  MPDS. 

C.  MAINTENANCE  PHASE 

In  1975  the  Fleet  Combat  Direction  System  support 
Activity,  San  Diego,  (FCDSSASD) ,  assumed  system  support 
responsibility  for  MPDS.  During  the  following  five  years, 
eighteen  major  changes  were  approved  and  released  which 
affected  one  or  all  of  the  following  major  systems: 

1.  Operating  System  (OS) 

2.  software  Maintenance  System  (SMS) 

3.  Equipment  Maintenance  Sub-system  (EMSSj 

4.  system  Magnetic  Tape  Retrieval  (SMR) 

[Ref.  4] 
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In  1976,  the  Navy  awarded  the  MPDS  software  Maintenance 
contract  to  syncrotech  Software  Corporation  in  San  Diego. 
This  contract  was  "sole  source”  and  went  to  Syncrotech 
because  they  employed  a  great  number  of  PRC  programmers  who 
were  involved  in  the  initial  development  of  MPDS  [Ref.  5]. 

D.  ADDITIONAL  INSTALLATIONS  OF  MPDS 

An  identical  copy  of  MPDS  was  later  installed  aboard  the 
OSS  Eisenhower  (CVN-69),  and  a  copy  is  presently  being 
installed  aboard  the  Vinson  (CVN-70) .  In  July  of  1973,  in 
response  to  the  Chief  of  Naval  Operations,  the  Naval  Elec¬ 
tronic  Systems  Command  began  a  project  called  the  Naval 
Modular  Automated  Communications  System  (NAVMACS) .  Since 
NAVMACS  was  designed  to  fulfill  the  communication  needs  of 
all  Naval  ships  and  the  carrier  version  NAVMACS  V-5  will 
soon  be  completed,  no  additional  copies  of  MPDS  will  be  pro¬ 
duced  for  future  carriers.  NAVSEA  has  also  authorized  the 
installation  of  the  NAVMAC  V-5  system  to  replace  the  MPDS 
onboard  the  OSS  Nimitz,  OSS  Eisenhower,  and  the  Vinson  as 
these  ships  enter  their  regular  overhaul  cycles. 
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HI.  ANALYSIS  OF  MPD5  DEVELOPMENT  PROCESS 


A.  HARDWARE  SPECIFICATIONS 
1 .  Available  Hardware 

The  initial  specifications  required  that  the  project 
office  '’utilize  equipment  units  or  designs  which  are  in 
being  and  readily  available'^  Ref .  6],  A  list  of  available 
equipment  follows: 


Name 

Central  Processor 
Magnetic  Disk 
Magnetic  Tape  Unit  (MTU) 


Designation 
CP-6423 
ED-28  1 
RD-294 


The  decision  to  use  available  equipment  offered  the 
possible  advantage  of  reducing  development,  cost  because  it 
is  much  cheaper  to  purchase  additional  units  than  it  is  to 
develop  the  initial  units.  It  also  helps  to  improve  the 
Navy's  Supply  System  Purchasing  Office’s  economies  of  scale 
since  it  serves  to  increase  the  overall  purchase  volume. 
This  procedure  also  conforms  to  the  Department  of  Defense 
Standardization  Program  which  requires  the  services  to  pur¬ 
chase  existing  equipment.  Using  existing  equipment  involves 
less  risk,  so  it  helps  prevent  cost  overruns  and  schedule 
slippages.  It  also  lessens  the  logistic  problems  which  are 
generally  associated  with  unique  equipment  items.  Items 
which  are  already  in  the  Navy  stock  system  often  have 
maintenance  contracts  established  with  the  vendors.  Unfor¬ 
tunately,  buying  existing  equipment  did  not  solv^  MPDS's 
logistic  problems  because  the  manufacturers  of  many  of  these 
vendors  stopped  producing  the  equipment.  Therefore 
replacement  has  become  increasingly  difficult  and  equipment 
overhauls  have  become  longer  and  more  costly. 

2 .  Hardware  Development  Items 

Many  hardware  items  which  were  required 
were  not  available  in  the  naval  stock  system  and 
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for  MPDS 
had  to  be 


contracted  out  for  development.  Several  of  the  major  equip¬ 
ments  which  had  to  be  developed  include: 


2ai§ 

Line  Printer 
Magnetic  Drum 
Display  Keyboard 


auction 
TT  624 
MO  570 
AN/UY\-9 


gogtyactor 
Data  Products 
RCA 

Burroughs 


The  Data  Accumulation  and  Distribution  Unit  (DADO) 
was  a  very  sophisticated  and  unique  piece  of  hardware  which 
was  developed  to  perform  the  system  multiplexor  function  for 
MPDS  [Ref.  7].  The  Electronic  Switching  Unit  (ESU)  was 
another  unit  which  had  to  be  developed  to  allow  all  three 
processors  access  to  the  magnetic  disk.  The  ESO  has  proven 
to  be  very  reliable,  but  its  failure  would  restrict  two  of 
the  three  processors  from  accessing  the  single  disk.  The 
OffI-43  is  a  device  used  to  interface  MPDS  with  the  fleet 
satellite  broadcast.  Common  User  Digital  Information 
Exchange  Subsystem  (CODIX) .  This  device  was  developed  after 
MPDS  was  accepted  for  fleet  use,  and  it  became  apparent  that 
MPDS  required  a  backup  system  which  would  provide  broadcast 
support  during  periods  of  major  equipment  failures. 

.3 .  Equipment  Specifications 

General  requirements  f c c  all  equipment  developed  for 
MPDS  are  referenced  in  the  specif ication  document  [Ref.  8]. 
Military  standards  were  referenced  which  set  equipment 
requirements  for  temperature,  shock,  resistance,  low  level 
signaling  and  reliability  [Ref.  9].  Functional  specifica¬ 
tions  for  the  hardware  included  processing  rates  required, 
code  which  it  must  be  capable  of  processing,  security 
requirements,  and  other  general  functional  requirements. 

4.  Areas  Mot  specified 

Difficulty  meeting  several  of  the  original  specifi¬ 
cations  arose  because  the  Navy  was  setting  standards  for  new 
equipment  which  was  destined  for  shipboard  use  and  had  to 


perform  functions  which  had  not  existed  prior  to  the 
project.  Consequently,  numerous  changes  were  proposed  and 
made  to  the  original  specifications  as  the  program  effort 
progressed  and  the  contractors  experience  improved  in  the 
new  development. 

3any  of  the  items  which  were  developed  for  the  pro¬ 
ject  clearly  lacked  detailed  specifications,  so  it  was  left 
to  the  personnel  in  the  program  office  and  the  contractors 
to  work  out  the  details.  The  result  was  a  description  of 
what  had  been  built  rather  than  a  specif ication  of  what  was 
to  be  developed  [Kef.  10].  Lack  of  specifications  offered 
the  advantage  of  allowing  the  program  office  and  contractors 
the  opportunity  to  make  important  changes  to  the  system's 
design  which  frequently  resulted  in  improved  system 
performance. 

One  change  which  improved  system  operation  was  the 
relocation  of  terminals  in  Radio  Central.  originally,  two 
terminals  were  to  be  used  for  control  and  placed  at  the  con¬ 
trol  console  with  another  terminal  placed  in  a  maintenance 
area.  The  program  office  altered  the  arrangement  by  placing 
all  three  terminals  at  the  control  console,  and  this  greatly 
improved  the  reliability  of  the  control  system  because  the 
AN/tJYA-9  terminals  have  experienced  a  low  mean  time  between 
failure  (MTBF)  and  a  high  mean  *iae  to  repair  (MTTR)  [Ref. 
11]. 

Lack  of  specifications  also  had  many  obvious  disad¬ 
vantages.  It  was  often  difficult  for  the  contractor  and 
pcogram  office  to  know  when  a  development  was  actually  fin¬ 
ished  because  they  had  nothing  to  compare  the  finished 
product  against  [Ref.  12],  It  proved  to  be  a  problem  with 
the  program  sponsors  because  they  would  complain  that  "the 
Navy  was  not  getting  what  it  originally  asked  for"  [Ref. 
13].  Allowing  the  project  office  the  freedom  to  design  the 
system  where  specifications  did  not  exist  tended  to 
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encourage  configuration  confusion.  It  is  vi+ally  important 
that  a  clear  design  pattern  be  outlined  in  the  specification 
to  prevent  the  developmental  effort  from  wandering  off 
course.  A  detailed  initial  set  of  specifications  would 
have  resolved  this  conflict. 

B.  SOFTWARE  SPECIFICATIONS 

The  original  specifications  required  all  software  to  be 
"modular  in  design  such  that  addition,  deletion,  or  change 
of  function  be  made  with  a  minimum  of  reprogramming"  [Eef. 
14].  The  requirement  that  the  software  be  modular  in  design 
was  fulfilled  by  the  contractors.  However  major  problems 
with  adding  modules  and  changing  functions  have  occurred 
during  the  maintenance  phase  because  of  excessively  high  CPU 
core  utilization.  The  specifications  did  not  set  utiliza¬ 
tion  limitations  upon  the  amount  of  core  which  the  programs 
were  permitted  to  consume.  The  requirement  for  the  contrac¬ 
tor  to  meet  performance  specifications  did  serve  to  limit 
the  amount  of  core  which  should  be  used  and  still  meet  per¬ 
formance  objectives,  but  allowances  were  not  made  for  future 
growth  and  program  enhancements  [Ref.  15]. 

1 .  Manual  Security  Measures 

The  Informational  Security  System  Design  for  MPDS 
was  extremely  important  because  MPDS  completely  changed  the 
structure  of  shipboard  message  handling  and  this  created 
numerous  new  security  concerns.  Prior  to  MPDS,  security  was 
provided  by  the  thick  metal  and  heavy  security  doors  around 
Radio  Central.  Distribution  security  was  accomplished  by 
restricting  access  to  those  individuals  who  were  designated 
in  writing  by  their  department  heads.  An  up-to-date  list  cf 
these  personnel  with  their  names,  security  clearances,  and 
the  highest  level  of  message  classifications  that  they  were 
authorized  to  receive  was  continuously  maintained  at  radio 
central..  This  listing  was  checked  any  time  an  individual 
reguested  message  distribution. 
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After  MPDS,  one  method  of  providing  additional  pro¬ 
tection  which  was  identified  in  the  specifications  was  a 
coded  device  which  would  be  used  at  the  remote  terminals  to 
inform  the  control  console  of  the  classification  level  of 
the  terminal  [Sef.  16].  A  security  card  reading  device  was 
never  developed,  but  a  manual  code  entry  device  was  devel¬ 
oped  whereby  the  user  could  type  in  his  classification  code 
and  have  messages  and  reports  distributed  to  his  terminal  at 
the  appropriate  classification  level. 

The  project  Office  was  afforded  considerable  lati¬ 
tude  in  developing  a  software  system  which  was  able  to  check 
the  validity  of  the  codes  entered  at  the  terminals.  An 
operating  system  security  module  was  developed  which  com¬ 
pared  the  code  of  the  user  to  a  Master  Security  List  (MSL) . 
The  MSL  contained  a  listing  of  all  the  authorized  users, 
their  codes  and  the  levels  of  security  which  they  were 
cleared  to  access  [Sef.  17],  The  specifications  also 
required  special  acknowledgement  for  receipt  of  top  secret 
materials.  Additionally,  the  completed  MPDS  provided  a  top 
secret  disclosure  sheet  to  assist  the  authorized  recipient 
in  maintaining  tight  control  over  the  sensitive  document. 

3.  Operating  System  Security  Potions 

'Jnfortunately,  the  projects  software  specifications 
did  not  address  in  detail  several  other  new  security  con¬ 
cerns  which  were  encountered  in  the  new  message  handling 
system.  One  critical  aspect  of  the  software  development 
which  was  not  addressed  specifically  was  the  security  pro¬ 
tection  to  be  provided  by  the  operating  system.  Since 
operating  systems  vary  widely  in  the  amount  of  protection 
which  they  provide  for  their  data,  it  is  prudent  to  specify 
the  exact  features  that  are  desirable  to  be  included  in  the 


system  to  be  developed. 


ISM  marketed  a  protection  mechanism  in  its  operating 
systems  called  "locks"  which  served  tc  prevent  unauthorized 
read/write  accesses  to  secure  blocks  of  memory.  IBM  also 
used  the  suparvisor/problem  mode  to  distinguish  between 
users  and  executive  states.  This  differentiation  helped 
prevent  unauthorized  alterations  of  instructions,  storage 
protection  locks,  and  the  operating  system  [Hef.  18]. 

The  Multics  operating  system  which  was  developed  by 
Honeywell  Information  Systems  offered  one  of  the  most 
advanced  security  systems  in  production.  It  offered  several 
sophisticated  features  which  were  not  available  on  IBM  Sys¬ 
tems.  Dne  important  component  was  the  internal  password 
encryption  which  served  to  prevent  illegal  disclosure  of  the 
master  password  list.  This  protection  was  accomplished  by 
encrypting  the  password  which  the  user  entered  and  comparing 
it  against  the  internal  password  file.  Therefore  if  a  sub¬ 
versive  agent  were  able  to  gain  access  to  the  computer  and 
capture  the  internal  password  file,  it  would  be  of  little 
value  to  him  without  the  encryption  code.  &  second  impor¬ 
tant  aspect  of  the  Multics  Security  system  was  the  use  of 
audit  trails  to  keep  a  record  of  the  users  who  accessed  the 
classified  data.  [Ref.  19].  This  procedure  is  extremely 
effective  when  the  users  review  the  audit  trail  on  a  regular 
basis  and  compare  it  against  their  access  logs. 

4 .  System  Vulnerability 

Security  safeguards  are  particularly  important  in  a 
multiprogramming/multiprocessing  environment  where  the  pro¬ 
cessors  are  required  to  handle  multiple  processes  at  the 
same  time.  These  processes  will  usually  have  different 
security  values  and  will  be  sharing  the  same  system 
resources.  A  system  or  device  which  can  guarantee  complete 
isolation  and  protection  of  the  secure  process  from  unau¬ 
thorized  access  or  disclosure  has  not  been  developed.  Even 
the  Multics  system  which  was  designed  with  security  as  one 
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of  its  primary  objectives  was  penetrated  by  a  special  U.S. 
Air  Force  Tiger  Team  who  was  tasked  to  assess  the  security 
of  the  computers  used  by  the  Air  Force.  Security  patches 
ware  used  to  correct  the  security  weaknesses  which  were  dis¬ 
covered  by  the  team,  but  these  patches  didn't  prevent  the 
Tiger  Team  from  making  additional  penetrations  by  exploiting 
other  system  weaknesses  [Ref.  20]. 

Attempts  to  upgrade  the  existing  level  of  MPDS  security 
to  include  some  of  the  features  present  in  MULTICS  would  be 
extremely  costly  and  would  not  guarantee  the  security  of  the 
system,  since  it  is  difficult  to  upgrade  security,  a  pro¬ 
gram's  sponsor  must  be  very  explicit  in  stating  in  the 
system  speci f ications  the  type  of  security  protection  that 
is  wanted. 

C.  CON PI 3 ORATION  CONTROL 

1 •  PCS  Specification 

The  control  of  system  configuration  proved  to  be  one 
of  the  most  difficult  problems  confronting  the  program  off¬ 
ice.  The  lack  of  precise  specif ications  was  one  of  the 
major  reasons  for  uncontrolled  growth  in  the  Facility  Con¬ 
trol  System  (PCS).  The  Military  Specification  for  the 
Message  Processing  and  Distribution  System  for  (CVAN-68) 
dated  30  Jan.  1967  required  the  following  monitoring 
capabilities : 

3.2.1.11  A  continuous  or  periodic  indication  of  suspected 
channel  trouble  shall  be  provided  to  the  Facilitv  Control 
Console  for  those  channels  being  processed  automatically. 

The  Specifications  also  provided  the  follow  guidance  on  how 
FCS  will  interface  with  MPDS. 

3.2.1.10  The  interface  between  the  MPDS  central  processor 

fnd  the  FCS  circuit  sapsing  multiplexer,  to  provide  for 
nput  of  the  communication  circuit  sensing  signals  to  the 
MPos  central  processor,  will  be  a  standard  I/O  channel  of 
the  central  processor. 
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To  comply  with  the  above  guidance,  the  project  off¬ 
ice  and  contractor  were  forced  to  decide  what  type  of 
sensing  mechanism  would  be  used  to  monitor  or  interrogate 
the  channels  and  how  often  the  sensing  should  take  place. 
Since  both  the  contractor  and  the  project  office  wanted  the 
best  system  for  the  Navy,  they  frequently  elected  to  develop 
a  system  which  offered  high  performance  as  opposed  to  a  less 
elaborate  system  which  offered  marginal  performance  at  a 
smaller  cost  [Ref.  21].  Many  other  decisions  had  to  be  made 
concerning  "how  to  fulfill  the  specif ications"  and  these 
eventually  caused  the  FCS  to  grow  in  size,  time,  and  cost. 

The  completed  FCS  would  have  provided  many  benefits 
to  the  ship’s  communication  personnel  for  it  would  have 
greatly  reduced  the  amount  of  manual  operator  intervention 
required  for  channel  and  terminal  connections.  It  also 
would  have  provided  an  increased  quality  control  capability 
which  has  been  desired  for  a  long  time  by  fleet  communica¬ 
tion  users. 

Despite  the  recognized  advantages  in  operator  cost 
reductions  and  improved  system  reliability,  the  development 
of  FCS  by  NELC  had  to  be  cancelled  by  NAVELEX  because  it  was 
exceeding  the  original  estimates  for  cost,  resource  utiliza¬ 
tion,  and  date  for  delivery  [Ref.  22].  The  amount  of  code 
and  its  corresponding  core  requirements  had  grown  to  such  a 
degree  that  it  was  estimated  that  the  completed  FCS  project 
would  have  required  additional  CP-642B  central  processing 
units  if  MPDS  was  to  continue  to  meet  the  original  perfor¬ 
mance  specifications. 

It  should  also  be  noted  that  the  implementation  of 
PCS  would  not  have  significantly  improved  MPDS'  message  dis¬ 
tribution  capabilities  nor  would  it  have  increased  the 
system’s  processing  speed.  The  primary  advavtages  of  FCS  lie 
in  it's  improved  guality  monitoring  and  reduction  in  the 
number  of  operators  required  to  manage  the  system.  Since  the 
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primary  objective  of  MPDS  was  to  correct  the  shipboard 
communication  deficiencies  of  slow  message  handling  and  poor 
message  distribution  which  were  revealed  during  the  3aseline 
II  Communications  Study,  it  is  apparent  that  the  PCS  could 
only  be  viewed  as  desireable  excess  feature. 

2.  Feasibility  Study 

a.  General  Approach 

In  June  of  1970,  Planning  Research  Company 
(PRC),  who  was  NELC's  software  contractor  for  MPDS,  did  an 
Intergration  of  Communication  System  Study  which  included  a 
Quality  Monitoring  Trade-off  Study.  The  goal  of  the  study 
was  to  determine  the  feasibility  of  integrating  an  Automatic 
Quality  Monitoring  System  ( AQMS)  and  a  Frequency  Monitoring 
System  (FMS)  with  MPDS.  AQMS  and  FMS  were  originally 
designed  to  be  two  subsystems  of  PCS.  Three  areas  of  feasi¬ 
bility  were  examined: 

1.  Technical 

2.  Cost/Benefit 

3.  Tine 

Positive  conclusions  were  drawn  about  the  feasibility  of  all 
three  areas.  PRC  did  recognize  the  interrelationships  bet¬ 
ween  cost  and  time  and  premised  their  positive  time 
feasibility  conclusions  upon  adequate  steady  funding. 

PRC  compared  the  relative  ease  of  operating  the 
AQMS  to  the  labor  intensive  Manual  Quality  Monitoring  System 
and  called  the  difference  one  of  the  benefits.  The  improved 
accuracy  was  also  considered  a  benefit.  The  contractor  did 
not  try  to  quantify  the  value  of  these  benefits.  The  amount 
of  risk  evaluated  for  the  project  was  consistently  rated  as 
low.  Appendix  (A)  provides  a  listing  of  the  additional 
equipment  and  software  required  to  develop  the  AQMS  and  the 
associated  degree  of  developmental  risk  [Ref.  23]. 
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b.  Cost  Computation 

PRC  presented  the  following  AQM  cost  formula  in 
their  Technical  Objective  VII  section  2.2.3: 

Cost  in  the  present  context  is  that  expenditure  associ¬ 
ated  with  the  implementation  of  AQM  expressed  as  a 

differential  cost  as  follows: 

C  =  C  -  c 

AQM  MQM 

where 

C  =  total  integrated  FC  system  cost 
AQM 

C  =  present  FC  system  cost 
MQM 

As  shown  above,  the  cost  for  AQMS  was  determined 
by  subtracting  the  cost  of  the  old  manual  system  from  the 
estimated  cost  of  the  automatic  system.  These  costs  were 
identified  in  Appendix  (3) .  The  exhibit  provides  a  detailed 
listing  of  the  additional  hardware  and  software  required  to 
develop  the  automatic  system  and  the  estimated  cost  associ¬ 
ated  with  each  item. 

c.  Additional  Cost  Factors 

In  addition  to  the  three  feasibility  studies 
mentioned  above,  it  would  have  been  beneficial  to  include  a 
section  of  study  on  organizational  feasibility.  This  sec¬ 
tion  would  quantitatively  evaluate  the  difficulties  which 
the  organization  (ship)  could  expect  when  implementing  the 
proposed  system. 

The  cost  of  implementation  can  become  quite  sev¬ 
ere  if  the  sailors  view  the  new  system  as  a  threat  to  their 
security.  These  feelings  often  develop  because  the  sailor 
was  not  trained  in  the  operation  of  the  new  system,  and  he 
feels  his  position  of  knowledge  and  authority  is  in  jeo¬ 
pardy.  The  sailors  may  respond  to  the  perceived  threat  with 
either  passive  or  active  resistance  [Ref. 24],  Any  resis¬ 
tance  to  a  new  system  will  invariably  cause  both  delays  in 
implementation  and  increases  in  the  final  project  cost. 
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although  it  is  often  difficult  to  accurately 
anticipate  the  exact  amount  of  resistance  which  will  be 
encountered  and  the  resulting  cost,  an  attempt  must  be  made 
if  the  project  costs  estimated  are  to  reasonably  resemble 
the  actual  cost.  MPDS  experienced  its  share  of  operator  and 
maintenance  personnel  passive  resistance,  and  it  is  reason¬ 
able  to  conclude  that  the  FCS  would  also  have  been  received 
by  the  ship's  crew  with  mixed  feelings. 

A  comprehensive  cost/benefit  analysis  would  also 
have  estimated  the  cost  of  training  the  fleet  sailors  to 
operate  and  maintain  the  proposed  system.  Appendix  (B)  and 
Appendix  (C)  do  not  address  these  costs.  These  areas  had 
the  potential  to  become  very  costly  for  several  reasons. 
The  fact  that  the  FCS  project  was  unique  to  the  large 
(CVN-68)  class  carriers  would  have  made  some  additional 
training  activities  necessary.  New  instructors  would  have 
to  be  trained,  class  training  pLans  and  lessons  would  have 
to  be  prepared,  and  training  materials  would  have  to  be  pur¬ 
chased.  All  of  these  efforts  and  expenses  would  have  been 
for  very  small  classes  and  would  have  to  be  completed  before 
qualified  personnel  could  be  sent  to  the  ship  to  operate  the 
new  system. 

PRC's  method  of  computing  the  cost  by  subtract¬ 
ing  the  cost  of  the  MQM  from  the  cost  of  the  AQMS  may  not 
have  revealed  the  full  cost  difference  because  AQMS  was 
designed  to  utilize  existing  MPDS  equipment.  This  utiliza¬ 
tion  imposes  a  cost  upon  the  entire  system  in  the  form  of 
either  reduced  performance  or  smaller  reserve  capacity  avai¬ 
lable  for  future  growth. 

In  order  for  the  Navy  to  have  made  a  completely 
knowledgeable  decision  about  the  feasibility  of  the  proposed 
project,  it  would  have  been  necessary  to  identify  all  of  the 
costs,  (including  cost  of  using  existing  systems) ,  and  to 
assign  quantifiable  values  to  the  benefits. 


3.  Report  generator 

Another  area  of  the  MPDS  project  development  which 
experienced  excessive  growth  was  that  of  reports  which  were 
generated  or  could  be  retrieved  at  the  remote  locations, 
rhe  military  specifications  addressed  this  issue  in  several 
locations. 


3.2.  1.9  Storage  and  retrieval  capabilities  for  long-term 
files  shall  be  provided. 

3. 2. 2.2. 5.1  It  shall  be  possible  to  retrieve  all  or 
selected  portions  of  the  log  information  either  on 
demand,  m  which  the  operator  inputs  a  request  to  the 
system  by  keyboard,  or  periodically,  in  which  case  the 
log  information  is  output  without  operator  information. 
Both  hard-copy  and  soft-copy  retrievals  shall  be  possi¬ 
ble. 


The  following  portion  of  the  specifications  provides 
a  general  framework  for  the  types  of  information  which  the 
system  would  be  required  to  accumulate  and  disseminate: 


3. 2. 2. 2. 5  Automated  message  accounting  shall  include: 

(a)  Attachment  of  unique  system  message  numbers  for 
accounting  and  retrieval  purposes. 

(b  Journalling  of  messages  for  accounting  purposes. 

(c)  Extracting  of  statistical  data  from  message 
traffic. 

(d)  Special  accounting  for  top  secret  message  deliv¬ 
ery  . 


To  determine  the  type  of  reports  required  and  the 
elements  of  data  which  have  to  be  accumulated  and  stored, 
the  project  office  consulted  with  the  users.  That  which 
resulted  was  a  system  which  was  originally  developed  to  pro¬ 
duce  47  different  reports  [Ref.  25],  This  placed  a  heavy 
burden  upon  the  entire  system  and  greatly  increased  the 
amount  of  secondary  storage  required  by  the  system.  These 
reports  were  printed  at  periodic  intervals  but  could  also  be 
retrieved  upon  demand  by  the  users  at  their  terminals,  pro¬ 
vided  the  requested  information  was  within  the  security 
range  of  the  user's  terminal.  Initially,  every  user  could 
retrieve  any  report  contained  within  the  system.  Since 
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retrieval  of  long  routine  reports  during  peak  message  load¬ 
ing  periods  severely  degraded  overall  system  performance 
and  a  genuine  need  to  know  could  not  be  substantiated  from  a 
terminal  retrieval  reguest,  future  changes  to  ;i?DS  res¬ 
tricted  report  production  to  scheduled  runs  unless  special 
off-line  requests  were  submitted  and  approved  [Ref.  26]. 

Recent  software  changes  which  have  been  released  to 
the  fleet  have  corrected  many  of  the  problems  with  the  ini¬ 
tial  report  package.  These  changes  have  limited  both  the 
content  and  distribution  of  several  periodic  reports. Surveys 
of  the  fleet  user  groups  have  resulted  in  adding  important 
tracking  programs  which  generate  reports  on  various  aspects 
of  system  performance. 

One,  recently  added,  provides  critical  information 
to  the  Oommunication  Officer  about  system  message  volume 
during  peak  loading  periods.  This  data  was  either  missing 
in  the  original  47  reports  or  it  was  obscurely  buried  where 
it  could  not  be  used  or  readily  accessed  by  personnel  who 
needed  the  information  [Ref.  27],  It  became  evident  that 
the  initial  querying  of  the  users  produced  an  inaccurate 
composite  of  their  requirements.  The  reports  which  MPDS 
produced  resembled  what  the  user  thought  that  they  wanted 
rather  than  what  they  truly  needed. 

This  lack  of  user  understanding  of  his  actual 
requirements  became  apparent  in  the  development  of  the  UI-9 
remote  receiver/transmitter  user  terminal.  Seventeen  func¬ 
tional  buttons  were  designed  into  the  terminals  to  satisfy 
the  users'  requirements.  Osage  patterns  have  shown  that  the 
operators  seldom  use  mors  than  six  of  the  functions.  Five 
of  the  other  functions  were  used  by  the  maintenance  person¬ 
nel.  The  net  result  was  six  user  specified  functional 
capabilities  designed  into  the  system  terminals  which  were 
not  productively  utilized  [Ref.  28]. 
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D.  TESTING 

1 .  Broadcast  Screening  Test  3b -^actives 

Special  testing  of  the  MPDS  broadcast  screening 
capability  was  conducted  by  Naval  Electronic  System  Command 
Southwest  Division  (NAYELECS YSCOMSOWESTDIY)  at  the  MPDS  test 
bed  at  NELC  on  May  14,  15,  16  and  13,  of  1973.  The  total 

test  time  was  28  hours.  Excerpts  of  real  world  live  traffic 
ware  taken  from  four  different  geographic  broadcast  areas  in 
the  Atlantic,  Eastern  Pacific,  western  Pacific,  and  the  Med¬ 
iterranean.  The  primary  objective  was  to  test  the  system's 
ability  to  correctly  compare  the  addresses  of  the  various 
broadcast  messages  against  the  addresses  contained  in  the 
MPDS  guard  list  (GML)  .  The  GM1  contained  approximately  150 
addresses  [Ref.  29].  A  second  test  objective  was  to  deter¬ 
mine  how  accurately  the  system  could  automatically  read  and 
distribute  the  incoming  message  to  the  appropriate  remote 
terminal. 

2.  System  Inprovement  Tests 

Several  System  improvement  Tests  (SIT)  were  also 
conducted  by  NA YELECS YSC3  MSOWESTD I Y .  These  SIT's  were  given 
to  evaluate  the  effectiveness  of  modifications  made  to  the 
hardware/software  subsystem.  Numerous  modif icatior.s  were 
made  to  the  system  for  the  purpose  of  resolving  Problem  Work. 
Sheets  [Ref.  30]. 

3 .  Users  Involvement  in  Testing 

The  Broadcast  Screening  Test  and  SIT  both  used  Nim- 
itz  (CYN-68)  crew  members  to  operate  the  system.  Utilizing 
the  future  operators  of  the  system  for  test  operations  pro¬ 
vides  many  advantages  to  the  project  team.  First  it 
provides  them  with  an  excellent  opportunity  to  train  the 
future  users  in  the  proper  operation  of  the  equipment.  It  is 
also  an  excellant  opportunity  to  instill  in  them  valuable 
confidence  in  the  system.  This  confidence  can  be  a  vary 
important  advantage  to  the  project  team  during  the 
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implementation  phase  [Ref.  31].  The  spirit  of  cooperation 
and  friendship  which  often  develop es  between  the  developer 
and  fleet  operators  daring  the  testing  phase  can  go  a  long 
way  toward  over  coining  the  skepticism  and  resistance  which 
often  plagues  projects  in  later  phases.  Finally,  the  project 
team  can  receive  important  feedback  from  the  operators  con¬ 
cerning  operational  difficulties  and  constructive 
suggestions  for  system  improvements. 

4 .  Restrictive  Testing  Procedures 

Mthough  the  primary  objective  of  testing  the  broad¬ 
cast  screening  capability  of  HPDS  was  fulfilled,  the  results 
of  the  test  were  obtained  under  very  restricted  conditions. 
Had  they  been  obtained  under  simulated  or  actual  operational 
conditions,  then  the  project  team  would  have  known  how  the 
system  would  function  when  it  encountered  the  technical  and 
human  stresses  associated  with  fleet  operations  [Ref.  32]. 
Message  and  report  retrievals  are  two  operations  which  sig¬ 
nificantly  increase  the  stress  upon  the  system.  Neither  of 
these  functions  were  permitted  during  the  Broadcast  Screen¬ 
ing  Test.  Experience  has  shown  that  •'■he  combined  effect  of 
these  two  processes  can  seriously  reduce  the  overall  effec¬ 
tiveness  of  system  performance. 
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A.  SUPPORT  ACTIVITIES 

1 .  FCDS SASD 

In  1975  FCDSSASD  was  originally  tasked  to  provide 
life  cycle  maintenance  for  the  Message  Processing  and  Dis¬ 
tribution  System.  To  facilitate  this  support,  a  special 
suite  of  equipment,  (identical  to  the  MPDS  equipment  onboard 
USS  Nimitz) ,  was  installed  at  FCDSSASD  [Ref.  33]. 

2.  NTSIC 

In  1979  the  Naval  Telecommunications  Systems  Inte¬ 
gration  Center  (NTSIC)  assumed  life  cycle  maintenance 
responsibilities  for  MPDS  [Ref.  3 U  ] .  NTSIC  has  a  duplicate 
model  of  the  MPDS  hardware  and  software  which  is  presently 
onboard  the  USS  Nimitz  and  USS  Eisenhower.  This  model 
serves  as  a  testing  facility  for  all  new  software  modifica¬ 
tion  and  hardware  changes  before  they  are  delivered  to  the 
fleet  for  installation. 

NTSIC  also  serves  as  coordinator  for  all  software 
change  proposals  (SCP)  [Ref.  35].  A  sample  list  of  SC?  can¬ 
didates  for  MPDS  software  change  release  #10  is  shown  ir. 
Appendix  (D) .  This  list  was  developed  by  sending  question¬ 
naires  to  the  fleet  users  and  compiling  the  results.  The 
candidates  for  change  were  then  discussed  with  the  senior 
communications  personnel  from  the  carriers  prior  to  the 
meeting  of  the  Communications  Change  Control  Board  (CC3) . 
Only  change  items  which  received  unanimous  user  support  and 
agreement  were  forwarded  to  the  formal  (CC3) .  Final  Comman¬ 
der  Naval  Telecommunications  (CNTC)  approval  for  software 
changes  is  based  upon  the  outcome  of  the  board.  NTSIC  is 
intimately  involved  with  every  step  of  this  process  [Ref. 
36  ]. 

3 .  Svncrotec  Software  Corporation 


The  MPDS  software  maintenance  contract  was  awarded 
to  Syncrotec  from  San  Diego.  The  fact  that  many  of  the 


original  NPDS  software  development  programmers  left  Planning 
Research  Corporation  (PRC) ,  (the  original  software  contrac¬ 
tor)  ,  and  went  to  work  for  Syncrotec  weighed  heavily  in  the 
decision  to  select  them  as  the  software  maintenance  contrac¬ 
tor.  Since  NPDS  had  unique  software  to  perform  difficult 
applications,  it  was  important  to  choose  a  software  mainte¬ 
nance  corporation  which  had  experience  with  the  system. 

B.  TRAINING 

1.  laiilaL-X&siial&fl 

Commander  Franson,  who  is  the  Deputy  Director  of 
NA  VTELSYSIC,  described  the  first  training  of  the  Nimitz's 
p-ecommissioning  crew  as  being  very  successful.  This  was 
de  in  part  to  the  high  priority  that  the  project  team 
placed  upon  utilizing  every  training  opportunity.  The  Exe¬ 
cution  Plan  for  Operational  Capability  Evaluation 
(OPCAPEVAL)  stated  the  following  training  objective: 

"  Every  effort  will  be  made  to  make  the  NPDS  available 
to  the  Nimitz  crew  for  training  during  contingency  per¬ 
iod." 

This  training  was  in  addition  to  practical  experience  which 
the  crew  members  obtained  while  operating  and  maintaining 
the  equipment  during  the  scheduled  test  periods.  Appendix 
(E)  provides  a  schedule  of  events  which  occurred  during  the 
OPCAPEVAL  and  the  long  periods  designated  for  system  train¬ 
ing  [  Ref.  37  ]. 

2 .  Operational  Training  Problems 

After  the  system  had  been  implemented  and  the  OSS 
NLmitz  became  operational,  training  deficiencies  began  to 
sirface.  These  deficiencies  became  especially  evident  when 
the  OSS  Nimitz  made  her  overseas  deployments.  In  a  trip 
report  from  two  Synchrotec  software  technicians,  the  follow¬ 
ing  comments  were  made  concerning  training  [Ref.  38]: 

"The  lasting  impression  that  remains  with  us  however,  is 
that  the  weakest  link  in  the  operation  and  performance 
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of  MPDS  is  now  unquestionably  the  operators  themselves. 
Knowledge  of  basic  communications  procedures  and  prac¬ 
tices  (let  alone,  knowledge  of  MPDS)  was  sadly  lacking 
among  many  of  the  segond  and  third  class  petty  officers 
aboard  ship,  and  until  the  sailors  are  familiar  with  how 
to  communicate  in  the  Navy  environment,  we  can  hardly 
expect  them  to  become  proficient  at  operating  MPDS." 

This  concern  about  the  level  of  shipboard  personnel  training 
was  also  shared  by  the  officers  onboard  the  USS  Nimitz.  In 
a  message  to  the  Commander  of  the  Sixth  Fleet  (COMSIXTHFLT)  , 
the  Commander  of  Task  Force  Sixty  (CTF  SIX  ZERO)  made  the 
following  comments  [Ref.  39]: 

"There  is  no  software  expertise  onboard  Nimitz  capable 
of  providing  the  level  of  support  that  recent  operations 
have  documented  as  required  to  maintain  MPDS  in  even  a 
marginally  operational  status.  .  .  .  The  onboard  soft¬ 
ware  techs  should  be  relieved  by  a  technician  qualified 
in  system  restoral  and  installation  of  system  fixes. 

It  is  clear  from  the  above  statements  that  the  shipboard 
technicians  lacked  understanding  about  how  MPDS  operated  and 
how  to  maintain  the  system.  This  leads  to  the  obvious  ques¬ 
tion  of  how  did  the  USS  Nimitz's  training  profile  drop  from 
its  initial  high  state  to  one  which  can  barely  maintain 
operational  capability. 

3 .  Scarcity  of  Instructors 

The  Commander  of  Naval  Education  and  Training 
(CNET) ,  who  is  in  charge  of  training  conducted  in  the  Navy, 
had  extreme  difficulty  finding  qualified  instructors  to 
teach  MPDS  operator  and  maintenance  classes.  There  are  sev¬ 
eral  reasons  why  this  problem  developed. 

a.  The  Commissioning  of  the  Eisenhower 

When  the  Eisenhower  got  commissioned,  it 
required  a  full  compliment  of  qualified  operators  and 
maintenance  technicians  to  take  her  to  sea.  Her  precommis¬ 
sioning  crew  did  not  have  the  advantage  of  being  able  to 
participate  in  the  system  development  of  MPDS  as  the  Nimitz 
precommissioning  had  done.  Consequently,  they  were  not  as 
well  trained,  and  qualified  personnel  had  to  be  acquired 


28 


r  m  wjmv 


V  '  C 


from  aither  the  Nimitz  or  ashore.  Since  the  training 
command  had  second  priority  to  fleet  units  for  personnel 
manning,  CNET  could  not  obtain  or  retain  the  instructors 
that-  it  needed  to  conduct  MPDS  classes  [Ref.  40]. 

b.  Sea/Shore  Rotation  Problems 

The  shortage  of  trained  personnel  combined  with 
the  expanding  need  for  sailors  who  possessed  dPDS  operation 
and  maintenance  experience  caused  a  serious  extension  of 
the  normal  sea/shore  rotation  interval.  &  sailor  could 
routinely  expect  to  receive  orders  from  the  JSS  Nimitz  to 
the  OSS  Eisenhower  rather  than  the  typical  rotation  ashore 
which  most  sailors  have  grown  to  expect.  The  net  effect  of 
this  extension  at  sea  has  been  a  severe  reduction  in  the 
number  of  qualified  personnel  staying  in  tne  Navy. 

c.  Civilian  Opportunities 

The  third  reason  for  CNET  being  short  of 
instructors  is  the  intense  demand  for  individuals  with  high 
technical  expertise  in  the  civilian  market.  These  civilian 
firms  usually  offer  very  high  starting  salaries  to  qualified 
personnel.  Since  MPDS  technicians  were  generally  some  of 
our  most  highly  trained  sailors,  their  marketability  was 
exceptionally  high.  With  the  rapid  exodus  of  highly  trained 
technicians  and  barely  enough  personnel  to  man  the  fleet 
units,  it  was  not  surprising  that  CNET  was  unable  to  provide 
the  necessary  number  of  instructors  to  conduct  the  courses. 

4 .  NTSIC  Solution 

Although  training  is  generally  conducted  by  CNET, 
the  lack  of  available  instructors  made  it  impossible  for 
CNET  to  adequately  train  the  NPD5  operators  and  maintenance 
personnel.  NTSIC  attacked  the  training  problem  in  two 
areas.  First,  they  sent  NTSIC  MPDS  specialists  onboard  the 
aircraft  carriers  during  their  deployments  to  train  them  in 
operating  and  maintaining  the  system  under  heavy  stress. 
Secondly,  they  offered  an  18  week  maintenance  course  and  a  9 
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week  operators  course  at  regular  intervals  to  prepare 
sailors,  who  were  ordered  to  the  USS  Nimitz  or  the  US 5 
Eisenhower,  for  their  jobs.  These  courses  have  proven  to  be 
very  beneficial  in  improving  the  ships'  capability  to  oper¬ 
ate  and  maintain  the  MPDS  with  their  own  personnel. 

5 .  Alternative  Design  to  MPDS 

a.  Description  of  NAVMACS 

Many  of  the  problems  encountered  in  training  the 
crews  of  the  USS  Nimitz  and  USS  Eisenhower  in  the  proper 
operation  and  maintenance  of  MPDS  have  not  been  experienced 
by  fleet  units  using  the  Naval  Modular  Automated  Communica¬ 
tions  System  (NAVMACS) .  The  N  A  V MACS  program  provides  a 
family  of  Automated  Communications  Systems  sized  to  meet  the 
needs  of  all  sizes  of  ships.  The  classes  of  NAVMACS  range 
from  the  most  basic  NAVMACS  VI  and  increases  in  sophistica¬ 
tion  and  capability  through  the  NAVMACS  V2,  V3,  and  V5.  The 
prime  advantage  of  this  system  is  that  the  more  complex  sys¬ 
tems  retain  and  build  upon  the  components  of  the  basic 
system.  Appendix  (F)  provides  an  example  of  how  the  more 
advanced  systems  utilize  the  standard  hardware  of  the  simple 
system  [ Ref.  41  ]. 

b.  Training  Advantages  of  Modular  Design 

The  above  approach  to  system  development  offers 
several  training  advantages  over  the  MPDS.  The  training 
task  is  much  easier  because  sailors  who  are  enroute  to  a 
ship  which  has  the  NAVMACS  VI  basic  system  installed  could 
be  trained  with  students  who  are  destined  to  serve  on  a 
NAVMACS  V3  ship.  This  is  possible  because  both  systems 
share  the  same  basic  modules.  The  problems  of  small  sized 
classes  and  lack  of  qualified  instructors  which  troubled 
MPDS  are  not  a  problem  with  NAVMACS  [Ref.  42  ].  CNET  has 
been  able  to  successfully  fill  its  instructor  billets,  and 
the  increased  size  of  the  classes  has  provided  CNET  with 
substantial  economies  of  scale. 
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c.  MPDS  Replacement  System 

The  NAVMACS  V5  will  offer  the  same  basic  message 
processing  and  distribution  services  as  MPDS.  It  is  cur¬ 
rently  scheduled  to  be  installed  on  all  of  the  future  CVN's 
after  the  Vinson.  It  is  also  scheduled  to  replace  the  MPDS 
units  on  the  Nimitz,  Eisenhower,  and  Vinson,  as  they  undergo 
their  regular  overhauls.  CNET  will  assume  training  respon¬ 
sibilities  for  this  system  [Ref.  43]. 

C.  MAINTENANCE 

1 .  System  Reliability  Problem 

System  reliability  is  one  of  the  greatest  concerns 
for  users  of  online  computer  systems  since  the  primary  rea¬ 
son  for  installing  such  systems  is  to  satisfy  the  need  for 
immediate  information.  This  need  for  reliability  becomes 
even  more  important  when  the  online  system  is  tasked  with 
carrying  tactical  and  strategic  intelligence  messages  which 
may  effect  the  wartime  readiness  posture  of  the  host  ship 
and  any  ships  subordinate  to  it. 

The  problem  of  MPDS  reliability  was  addressed  in  a 
letter  from  the  commander  of  Carrier  Group  Two  (who  was 
embarked  onboard  the  OSS  Niaitz)  to  the  Commander  Naval  Air 
Force,  O.S.  Atlantic  Fleet. 

Erratic  reliability  was  the  primary  MPDS  deficiency. 
The  fact  that  reliaoility  invariably  declined  as  traffic 
volume  rose  made  unreliability  a  particularly  sensitive 
problem.  .  .  .  Reliability  of  99.  S']  is  considered  a  rea¬ 
sonable  standard  of  satisfactory  performance  [Ref.  45]. 

2.  Equipment  Problems 

Many  of  the  hardware  items  which  were  developed 
especially  for  MPDS  became  maintenance  problems.  Low  mean 
time  between  failures  (MTBF)  and/or  lack  of  replacement 
parts  were  the  two  primary  reasons  for  excessive  system  down 
time.  Following  will  be  a  discussion  of  hardware  problems 
related  specifically  to  the  Data  Acquisition  and  Distribu¬ 
tion  Unit  (DADO)  and  to  the  MO  570  Drum: 
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a.  The  DADO 

The  Data  Acquisition  and  Distribution  Unit 
(DADO)  TD  1066,  which  functions  as  an  input/output  control 
interface  unit,  is  unique  in  design  and  is  considered  essen¬ 
tial  for  normal  operations.  This  unit  has  been  a  continuous 
maintenance  concern  since  the  system  was  first  installed  on 
the  Nimitz  in  19^4.  The  supervisor  of  Shipbuilding  at  New¬ 
port  News,  Virginia,  wrote  the  following  comments  to  Admiral 
Kidd  about  the  need  for  logic  and  control  printed  circuit 
cards  for  the  DADO. 

No  replacement  cards  are  available  to  immediately 
satisfy  Nimitz's  demands  when  one  of  these  .  .  .  cards 
fail,  which  is  often.  It  has  become  apparent  that  lit¬ 
tle  attention  has  been  given  to  ensuring  adequate 
provisioning  for  unique  HPDs  hardware  [Ref.  45]. 

DADO  failures  have  frequently  interrupted  normal  shipboard 
message  communication  since  its  initial  installation .  Its 
breakdowns  have  necessitated  Synchrotech  maintenance  spe¬ 
cialists  to  take  long  ship  rides  with  the  OSS  Nimitz  to  fix 
the  DADO  and  restore  the  system  to  normal  operational 
capability. 

Operational  units  were  not  the  only  activities 
to  suffer  degraded  mission  readiness  because  of  the  unrelia¬ 
ble  equipment.  The  Fleet  Combat  Direction  systems  Support 
Activity  which  originally  provided  life  cycle  support  for 
HPDS  also  experienced  operational  interruptions  due  to  DADO 
failures.  This  was  due  primarily  to  the  lack  of  complete 
logistic  support.  The  failures  resulted  in  a  substantial 
reduction  in  the  unit's  ability  to  meet  fleet  support 
requirements  [Ref.  46]. 

In  March  of  1978,  Capt.  A.E.  Huff  0SN3,  who  was 
a  hardware  system  engineer  for  Martin  Marietta  Company  in 
Denver,  Colorado,  did  an  analysis  of  MPDS  during  his  two 
weeks  of  active  duty  with  the  Naval  Electronic  Systems  Com¬ 
mand.  He  made  the  following  remarks  about  the  DADO: 
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Since  only  four  of  these  DAD'J  units  Dresently  exist,  the 
ESO  procures  replacement  boards  on  an  "as  call  basis". 
This  creates  longer  than  usual  replacement  time  and 
costs  around  $1000  per  card  [Ref.  47]. 

Capt.  Huff  stated  that  an  item  which  could  serve  as  a 
replacement  for  the  DADO  is  a  unit  called  MICS.  It  is  cur¬ 
rently  being  used  by  the  Air  Force's  Strategic  Air  Command 
with  apparent  success.  The  modern  circuit  technology  used 
in  MICS  is  estimated  to  reduce  maintenance  cost  by  as  much 
as  90]  and  greatly  increase  reliability, 
b.  MO  570  Drum 

MPDS  was  designed  with  two  drums  to  provide 
added  capacity  and  redundancy.  The  initial  specifications 
called  for  a  single  IBM  disk  unit,  but  the  contractor.  Plan¬ 
ning  Research  Corporation  (PRO  ,  wisely  convinced  the 
Government  Project  Office  of  the  need  for  the  increased 
speed  which  was  available  in  the  M0  570  magnetic  drums  [Ref. 
48],  The  drums  have  also  been  characterized  by  low  lMTBF  and 
frequent  logistic  problem.  However,  the  failure  of  one  drum 
does  not  force  the  entire  system  to  shut  down,  which  is  what 
occurs  when  the  DADO  fails.  This  is  because  the  second  drum 
is  capable  of  supporting  the  system  in  a  degraded  mode, 
c.  General  Hardware  Char acteristics 

MPDS  was  designed  with  a  tremendous  amount  of 
hardware  redundancy.  The  system  is  programmed  to  gracefully 
die  without  interrupting  normal  message  processing  until  the 
last  spire  unit  collapses.  This  feature  of  MPDS  is 
extremely  valuable  when  the  system  is  experiencing  heavy 
loading  while  fulfilling  operational  commitments.  During 
these  periods,  it  would  be  very  difficult  to  shut  down  the 
system  for  troubleshooting,  so  the  designers  made  this 
procedure  unnecessary  by  providing  sufficient  equipment 
spares  to  allow  the  system  to  continue  to  operate  [Ref.  49]. 

3.  laissioos  to  the  Functional  Description 

Several  maintenance  problems  surfaced  when  the  fleet 
users  discovered  that  the  new  system  did  not  do  everything 
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that  they  needed.  Two  areas  which  were  of  particular 
concern  to  the  users  were  message  storage  limitations  and 
NATO  message  handling. 

a.  Message  Storage  Limitations 

The  Commander  of  Carrier  Group  Two,  who  was 
embarked  onboard  the  USS  Niraitz,  was  deeply  concerned  about 
the  system's  limited  online  message  retrieval  capability. 
He  wrote  the  following  comments  in  a  letter  to  his  Command¬ 
ing  Officer: 

The  existing  MPDS  capacity  did  not  provide  sufficient 
online  message  storage  to  oermit  more  extensive  user 
recall  of  recent  messages  .  .  .  hence  duplicate  paper 
files  were  maintained  to  provide  copies  of  messages  that 
had  been  removed  from  online  storage.  Ten  davs  of 
online  message  recall  capability  is  considered  a  reason¬ 
able  target  [Hef.  50]. 

Although  the  system  was  obviously  not  providing  adequate 
message  retrieval  services,  it  was  performing  up  to  the 
standards  outlined  in  the  Functional  Description.  The  fol¬ 
lowing  is  the  message  storage  requirement  contained  in  the 
Functional  Description: 

3.2.1.10  System  messages  and  associated  .  .  .  entries 
shall  be  stored  for  approximately  three  days  on  online 
mass  storage  to  support  duplicate  search.  message 
retrieval,  report  generation  and  other  functions  [Ret. 
51]. 

b.  NATO  Message  Processing 

The  capability  to  process  North  Atlantic  Treaty 
Organization  (NATO)  message  traffic  was  not  included  as  part 
of  the  automated  MPDS.  Consequently,  the  USS  Nimitz  was 
required  to  process  NATO  traffic  manually  during  a  large 
part  of  her  deployment  to  Furope  [Hef.  52].  Several  tempo¬ 
rary  patches  were  made  to  the  system  to  allow  for  partial 
automated  handling  of  NATO  messages.  The  Commander  of  Task 
Force  Sixty  wrote  the  following  to  the  Commander  of  the 
Sixth  Fleet: 


Without  the  partial  automated  SATO  processing  capability 
achieved  by  patches.  the  task  (of  processing  all  of  the 
NATO  traffic)  would  have  been  close  to  impossible  [Ref. 

5  3  ]  • 

The  Functional  Description  for  MPDS  made  no 
requirements  for  NATO  automatic  message  processing  capabili¬ 
ties.  A  permanent  software  change  to  allow  automatic 

processing  of  NATO  messages  was  installed  onboard  the  OSS 
Nimitz  after  the  completion  of  the  deployment, 
c.  Message  Traffic  Estimates 

Naval  telecommunications  message  traffic  has 
been  increasing  each  year  as  the  quality  and  speed  of  ser¬ 
vice  has  continued  to  improve.  The  Military  Specifications 
for  MPD5  were  written  in  1967  when  the  average  traffic 
volumes  for  aircraft  carriers  were  much  lower  than  what 
would  be  found  in  the  fleet  today.  The  following  MPDS 
requirements  are  taken  from  the  original  Military 
Specification: 

3.1.14  Data  rates  and  capacity. — The  system  when  oper¬ 
ating  "on-line"  shall  ...  be  possible  to  handle  up  to 
2500  average  messages  per  day  and  to  retrievably  store 
up  to  7500  average  messages. 

3.1.13  Average  traffic  units. --System  capacity  and  pro¬ 
cessing  rate  requirements  herein  shall  be  based  on  an 
average  message  length  of  200  words  [Ref.  54]. 

The  average  length  of  messages  has  increased  to  above  200 
words  because  fleet  units  are  now  sending  more  administra¬ 
tive  traffic  over  the  fleet  broadcast  which  used  :o  be 
delivered  by  mail. 

MPDS  has  been  required  to  process  average  mes¬ 
sage  volumes  in  excess  of  3500  massages  per  day  when  the  USS 
Nimitz  had  the  Task  Force  Commander  embarked  during  major 
fleet  exercises  in  the  Mediterranean  Sea  [Ref.  55]. 

4.  The  Effects  of  Operations  Qpon  Maintenance 

The  urgent  necessity  of  intense  fleet  operations  has 
frequently  been  the  cause  for  delays  in  both  corrective  and 
scheduled  maintenance.  During  the  1976  deployment  of  the 
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DSS  Nimitz,  several  hardware  and  software  problems  developed 
which  could  not  be  handled  by  the  ship's  maintenance  crew. 
Synchrotech  sent  a  software  team  aboard  the  carrier  during 
part  of  the  deployment  to  correct  problems  and  make  recom¬ 
mendations  for  system  improvements.  Following  are  a  few 
comments  made  by  the  software  specialist  concerning  their 
shipboard  experience: 

It  is  nearly  impossible  to  debug  a  software  system  in  an 
operational  environment,  expecially  with  traffic  volumes 
which  are  typically  associated  with  a  flag  command.  The 
system  cannot  be  surrendered  to  the  exclusive  use  of 
programmers  to  test  apd  debug  ...  an  outage  of  even  30 
minutes  creates  traffic  backlogs  untenable  to  the  staff 
and  ship  users  (Ref.  56]. 

It  is  evident  from  the  above  statement  that  a  system  with 
low  MTBF  would  function  more  successfully  in  an  intense 
operational  environment.  Another  way  of  solving  the  mainte¬ 
nance  problem  is  to  design  a  system  which  offers  a  short 
mean  time  to  repair  (MTTR) .  Many  systems  are  available 
today  which  are  modularly  constructed  to  allow  average  tech¬ 
nicians  to  pull  the  defective  module  and  insert  a 
replacement  module  in  a  very  short  time  frame. 

5 .  Improved  Reliability 

J1 PDS  has  now  been  in  the  fleet  for  six  years.  Dur¬ 
ing  this  time  the  operators  and  maintenance  personnel  have 
acquired  a  wealth  of  valuable  knowledge  about  the  system. 
This  increased  knowledge  has  enabled  the  fleet  users  to 
maintain  the  system  in  a  higher  state  of  readiness.  Many  of 
the  original  maintenance  problems  were  due  to  the  fact  that 
it  is  difficult  to  maintain  an  unfamiliar  system  regardless 
of  the  level  of  technical  expertise  of  your  personnel  [Ref. 
57]. 

Synchrotech  software  specialists  were  called  aboard 
the  OSS  Nimitz  to  solve  several  technical  problems  which 
appeared  to  be  beyond  the  technical  ability  of  the  ship's 
maintenance  crew.  The  software  specialist  said  the 
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fallowing  about  the  magnetic  drum  failures  in  the  trip 
report  which  they  submitted: 

Magnetic  drums — The  message  file  clerics,  who  use  a  work 
area  and  table  which  is  mounted  directly  in  front  of  the 
drums,  were  stacking  burn  bags  (baqs  full  of  old  mes¬ 
sages  which  are  scheduled  to  be  burned)  on  the  floor 
directly  in  front  of  the  drum.  This  restricted  the 
badly  needed  air  circulation  required  by  the  MU-570  drum 
to  maintain  a  reasonable  ambient  air  temperature,  and 
the  drum  beaan  experiencing  intermittent  errors.  Remo¬ 
val  of  the  bags  resolved  the  problem  [Pef.  58]. 

This  is  an  example  of  how  the  operators  learned  valuable 
information  about  the  heat  sensitivity  of  the  drums  and  the 
air  circulation  patterns  in  the  computer  room.  This  infor¬ 
mation  should  be  available  for  future  operators  of  the 
system  and  consequently  further  heat  problems  with  the  drums 
should  be  avoided.  The  net  summation  of  these  learning 
experiences  is  quite  often  a  more  reliable  system. 

Another  factor  contributing  to  improved  performance 
was  the  installation  of  18  software  releases  by  FCDSSASD  and 
NTSIC  [Ref.  59].  These  software  releases  have  provided 
incremental  improvements  to  the  operating  system,  mainte¬ 
nance  subsystems,  and  the  retrieval  subsystem.  They  have 
added  the  capability  to  process  RATO  messages,  accumulate 
and  process  useful  data  for  periodic  reports,  and  generally 
improve  overall  system  performance. 
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V  CONCLUSION  AMD  RBCOHKEHDATIOHS 


A.  OVERVIEW 

The  MPDS  project  history  has  provided  a  classic  example 
of  how  failure  can  occur  in  the  military  computer  acquisi¬ 
tion  process.  This  failure  was  the  result  of  the  Navy  not 
giving  sufficient  attention  to  four  major  elements  of  the 
acquisition  process. 

The  first  and  primary  problem  was  the  Navy's  failure  to 
do  detailed  planning  at  the  beginning  of  the  project  prior 
to  initial  developmental  work.  Inadequate  time  spent  upon 
planning  resulted  in  the  project  not  having  a  well  mapped 
course  to  follow.  Cost  over  runs  and  problems  with  mainte¬ 
nance,  training,  and  logistics  could  also  be  attributed  to 
poor  planning.  Eighteen  change  releases  by  the  Navy's  sys¬ 
tem  support  activities  were  required  to  correct  many  of  the 
problems  which  had  their  origins  in  the  system  planning 
phase. 

Failure  to  freeze  the  design  early  in  the  project  was 
another  significant  problem  with  the  developmental  process. 
The  Facility  Control  System's  design  was  permitted  to  change 
and  grow  until  the  system  had  to  be  terminated  because  it 
was  going  to  make  the  entire  MPDS  project  late  and  drive  the 
total  cost  of  the  project  beyond  acceptable  limits.  Project 
scheduling  problems  developed  because  no  one  knew  when  the 
FCS  would  be  finished  since  it  was  not  known  what  the  fin¬ 
ished  product  was  supposed  to  look  like. 

Ambiguous  and/or  incomplete  military  specifications  also 
contributed  to  the  project  office's  problems.  The  project 
office  had  to  make  design  decisions  on  an  adhoc  basis  with¬ 
out  the  benefit  of  the  explicit  directions  usually  contained 
in  the  specifications.  The  composite  of  these  decisions  was 
a  system  which  provided  too  many  reports  of  minimal  value, 
terminal  functions  which  were  not  used,  and  which  could  not 
operate  in  a  NATO  environment. 
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Finally  a  comprehensive  cost/benefit  analysis  was  never 
performed  to  determine  the  true  feasibility  of  the  proposed 
systems.  The  high  risk  associated  with  the  FCS  was  never 
fully  recognized  in  the  feasibility  study.  Alternative  sys¬ 
tems  were  not  considered  in  the  feasibility  study.  As  a 
result  of  the  above,  the  service  wasted  a  lot  of  money  while 
pursuing  the  development  of  a  system  which  never  material¬ 
ized.  The  lack  of  alternative  systems  in  the  feasibility 
study  deprived  the  Navy  of  the  option  to  select  a  more 
appropriate  design.  Appendix  (G)  lists  several  of  the  alter¬ 
native  design  options  which  were  available  for 
consideration. 

B.  RECOMMENDATIONS 

More  time  needed  to  be  spent  in  the  planning  phase  to 
prepare  a  comprehensive  Configuration  Management  Plan, 
Training  Plan,  Security  Plan,  and  Integrated  Logistic  Sup¬ 
port  Plan.  These  documents  would  have  provided  yuick 
reference  for  the  project  team  to  use  when  confronted  with 
major  decisions.  The  plans  wouLd  have  contained  procedures 
for  establishing  a  change  control  board  and  would  have  out¬ 
lined  the  major  project  objectives  for  training,  security, 
and  logistics.  Such  detailed  guidance  was  badly  needed  by 
the  MPDS  project  team  and  would  have  prevented  many  of  the 
problems  which  resulted  from  the  aihoc  decisions.  [3ef.  63] 

A  Program  Plan  which  provided  for  periodic  reviews  would 
also  have  been  helpful  to  the  project  team.  One  of  the- 
functions  of  the  review  team  would  be  to  consider  freezing 
the  system/subsystem's  design.  Early  freezing  of  the  FCS 
design  could  have  prevented  that  system's  development  from 
falling  behind  schedule. 

Future  computer  system  acquisitions  should  place  heavy 
emphasis  on  preparing  thorough  and  clear  specifications. 
This  could  be  accomplished  by  establishing  a  specification 
review  team  consisting  of  both  system  sponsors  and  technical 
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users  who  will  initially  verify  the  original  specification 
and  who  would  later  approve/disapprove  specification 
changes.  This  would  have  prevented  many  of  the  problems 
which  occurred  in  the  MPDS  project  where  the  users  and  spon¬ 
sors  received  a  product  which  was  different  than  they  had 
requested. 

Concise  specifications  have  the  advantage  of  focusing 
heavily  upon  the  end  product.  Such  focus  tends  to  prevent 
the  technicians  from  becoming  overly  intrigued  with  the 
technical  sophis tication  of  their  system  and  forces  them  to 
concentrate  on  developing  an  end  product  which  matches  the 
specification.  This  procedure  would  limit  or  reduce  the 
problem  of  acquiring  extremely  sophisticated  hardware  and 
software  as  the  Navy  did  with  MPDS  because  the  developers 
would  not  be  given  a  blank  specification  sheet  where  they 
could  fill  in  the  details. 

To  ensure  compliance  with  the  above  objectives,  it  is 
recommended  that  project  Sponsors  include  them  in  the  Letter 
of  Instruction  (LOI) ,  which  signals  the  beginning  of  the 
acquisition  process.  By  placing  these  requirements  at  the 
on-set  of  the  project,  they  will  receive  the  attention  that 
they  require  at  the  appropriate  time. 
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APPENDIX  A 


AQM  ADDITION  DEVELOPMENT  BISK  ESTIMATES 


—  — 

Development  Risk  Function 

Risk.  Estimate 

QUALITY  MONITORING  SYSTEM 

Signal  Sensor  and  Samplers 

low 

Scanner-Multiplexer  Converter  (A/O) 

low 

Frequency  Monitoring  System 

-  ------ 

low 

Quality  Monitoring  Software 

low* 

Frequency  Monitoring  Software 

low* 

L  .  . .  -  ..  — ,  1 

*  Predicated  upon  the  availability 
of  adequate  support  software 


APPENDIX  B 


AQM  DIFFERENTIAL  COST  ESTIMATES 


COST  ELEMENTS 

COST  ($K) 

-  .  I 

QUALITY  MONITIORINS  SYSTEM 

Signal  Sensors  and  Samplers 

5 

Signal  Conditioners 

7 

Scanner  Multiplexer 

14 

A/0  converter 

1 

Frequency  Monitoring  System 

10 

-  ...  - . 

------  -  -  | 

Installation 

r 

17 

Quality  Monitoring  System  Software 

10 

Frequency  Monitoring  System  Software 

15 

Total=$79)c 
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APPENDIX  D 


OPEN  SCP»S  MPDS  C7N-68  CLASS 


— 

SCP  REL  9.0 

E“  EStEi-5  i2'2  Pre  CTC 

CCB  CVN-68  CVN-69  CVN-70  CC3  NTSIC  CCB  APPR 

—  - 

0  00  2  # 

0003  # 

0004 

0005  # 

0006 

0007 

X$  X  HSHSHS 

C  H  H  H 

0008 

0  009 

0010 

0011 

X  S  X  H  $  H  $  H  $ 

C  X  C  C  C 

XX  XXX 

X  XXX 

0012 

0014  # 

0016 

0017  ?  $ 

X  $  X  H  $  H  $  H  $ 

X  C  C  C  C 

X 

0018 

0019 

0020 

0023  # 

X  XX  XXX 

X  c  c  c 

c  c  c  c 

0  02  5  # 

0026 

0027 

0030 

X  c  c  c  c 

X  C  H  H 

C  C  H  H 

*  -  Approved  bv  last  CCB  for  Rel  9.0 
?  -  Request  CNTC  Approval  for  Rel  9.0 
X  -  Recommended  or  Requested  for  Rel  10.0 
H  -  Recommended  for  Hold  Open 
C  -  Recommended  for  Cancel 
R  -  Review 
$  -  Require  ECP 
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APPENDIX  E 


OPCAPEVAL  TEST  SCHEDULE  OF  EVENTS 


[ 

r 

— 

DATE 

TEST/EVENT 

r 

[test  period 

|  20-22  Aug  1973 

Interconnection  Verification  Test 

23-24  Aug 

On-Line  Confidence  Test 

Off-Line  Confidence  Test 

25  Aug 

Security  Composite  Test 

P-Series  on  System  10 

26-28  Aug 

OPCAP  Phase  III  on  System  10 

29-30  Aug 

System  Debug  System  11  Preventive 
Maintenance  Test  System  11 

31  Aug 

Security  Composite  Test  p-Series 
on  System  11 

1-5  Sept 

OPCAP  Phase  III  Test  on  System  11 

6-7  Sept 

System  debug  System  11 

8-10  Sept 

Nimitz  Crew  Training 

11-12  Sept 

System  Debug  System  11 

13-15  Sept 

OPCAP  Phase  IV-A  Test  on  System  11 

16-18  Sept 

OPCAP  Phase  IV-A  Test  on  System  11 

19-20  Sept 

System  Debug  System  11 

21-23  Sept 

Contingency 

24-30  Sept 

Standard  Measurement  Technique  (SMT) 

24-27  Sept 

Nimitz  Crew  Training 

28-30  Sept 

Contingency  (End  of  Test  Period  A) 

TEST  PERIOD 

1-6  Oct 

B 

OPCAP  Phase  IV  Test  Demonstration 
on  System  11 

__  —  _ 
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APPEHDIX  P 

NAVMACS  H ARD9ARE  MODULARITY  MATRIX 


■ 1  — — - - -  - —  — 

EQUIPMENT 

NAVMACS 

VI 

AN/UGC-25 

PAGE  PRINTER 

4 

1 

AN/UGC-20 

CONTROL  TTY 

1 

AN/UYK-20 

MI HI COMPOTE R 

1 

0  N— 14  3 

INTERFACE  GROUP 

1 

1  "  1 

RD-397  PAPER  TAPE 
READER  PUNCH 

1 

CV-30  22 

LEVEL  CONVERTER 

1 

AN/USH-26  MAGNETIC 
TAPE  ONI T 


TT-624  MEDIUM 
SPEED  PRINTER 


lN/USQ' 

CEYBOA 


KEYBOARD/DI  SPLAY 


RD-433 
DISK  FILE 


KEY BO ARD/PR INTER 


■  —  ■ 

NAVMACS 

NAVMACS 
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V2 

V3 

V  5 
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A.  SYSTEM  SELECTION 

1 .  Basic  Criterion 

The  most  important  decision  that  the  Communication 
Planners  had  to  make  was  concerning  the  selection  of  the 
type  of  system  which  they  were  going  to  develop  for  instal¬ 
lation  onboard  the  Nimitz.  The  system  had  to  satisfy  the 
major  communications  objectives  of  reducing  human  interven¬ 
tion,  increasing  processing  speed,  as  well  as  being  able  to 
handle  the  extremely  large  volumes  of  message  traffic  nor¬ 
mally  associated  with  air  craft  carriers  and  their  embarked 
Flag  Officers'  staffs.  Important  decisions  had  to  be  made 
concerning  the  number  of  manual  activities  to  be  automated, 
what  functions  should  be  placed  online,  and  what  processing 
speeds  should  be  obtained. 

2.  Alternative  Design  Approaches 

a.  Semi-Automatic 

The  MPDS  developed  for  the  USS  Oklahoma  City 
(CG-5)  is  an  example  of  a  system  which  satisfied  the  stated 
objectives  while  using  minimal  hardware  and  software 
resources.  The  automated  features  of  this  system  did  not 
include  remote  terminal  message  and  report  retrieval  ser¬ 
vices.  Nor  did  it  allow  for  remote  terminal  message 
transmission . 

b.  Pully  Automated 

The  MPDS  developed  for  the  CSS  Nimitz  offered 
maximum  automation,  high  processing  speeds,  and  very  high 
message  processing  rates.  The  hardware  and  software  were 
characterized  by  high  interdependancies  and  sophistication. 

c.  Hybrid  Approach 

Many  combinations  of  semi-automated  and  fully 
automated  features  were  available  for  the  planners  to  con¬ 
sider.  Any  system  which  performed  the 

basic  automated  functions  of  the  (CG-5)  system  would  fall 
into  this  category. 


a.  Semi-Automated  System 

The  semi-automated  system  was  built  from  exist¬ 
ing  hardware.  It  took  minimal  time  to  become  fully 
operational.  The  cost  to  develop  the  CG-5  system  was  rela¬ 
tively  low. 

b.  Fully  Automated  System 

The  CVN-68  system  offered  many  online  services 
to  the  users  such  as  remote  terminal  message  services  [Ref. 
60].  These  services  have  increased  user  productivity  and 
communications  accuracy. 

4 .  Oisa  dvantages 

a.  Semi-Automated 

This  system  requires  a  lot  of  manual  interven¬ 
tion  in  the  message  handling  process.  The  users  have  to 
walk  their  outgoing  messages  traffic  to  Radio  Central.  Mes¬ 
sage  retrievals  take  a  relatively  long  time  to  process. 

b.  Fully  Automated 

The  primary  disadvantages  are  high  development 
cost  and  maintenance  difficulties  due  to  the  high  sophisti¬ 
cation  of  the  hardware  and  software. 

5 .  Planners1  Choice 

The  planners  had  to  make  a  performance/cost  trade¬ 
off  in  selecting  the  communications  system  for  MPDS.  The 
decision  to  develop  a  highly  automated  system  reflects  the 
planners'  emphasis  on  maximum  performance. 


B.  HARDWARE  AND  SOFTBABE  SELECTION 

Another  important  area  which  was  of  concern  to  the  plan¬ 
ners  was  hardware  and  software  selection.  Plans  had  to  be 
made  outlining  policy  on  the  use  of  existing  hardware  and 
software.  Decisions  had  to  be  made  concerning  what  specifi¬ 
cations  would  be  used  for  items  that  had  to  be  developed. 
The  decisions  made  by  the  planners  can  be  found  in  the 


Military  Specification  and  the  Functional  Description.  The 
results  of  these  decisions  can  be  observed  onboard  the  USS 
Nimitz  and  USS  Eisenhower. 

1 .  Utilize  Existing  Units 

The  planners  decided  to  use  existing  equipment  and 
design  where  they  were  available,  for  MPDS  [Ref.  61].  The 
pieces  of  equipment  which  were  to  be  used  were  listed  in  the 
Military  Specif ications. 

2 .  Develop  New  Units 

Another  approach  would  have  been  to  develop  an 
entirely  new  suite  of  hardware  and  software. 

3 .  Alvanta  ges 

a.  Utilize  Existing  Units 

Several  savings  can  be  obtained  by  using  exist¬ 
ing  units.  The  project  can  save  a  lot  of  time  and  money  by 
not  having  to  develop  a  new  unit.  The  amount  of  risk 
involved  in  the  development  is  also  much  lower  when  one  has 
a  known  reliable  unit  in  stock. 

b.  Develop  New  Units 

The  major  advantage  to  developing  new  units  is 
increase  in  performance. 

4 .  Disadvantages 

a.  Utilizing  Existing  Units 

The  existing  units  may  be  functioning  below  the 
standards  of  the  new  equipment.  Opportunities  for  improved 
performance  may  be  lost  because  outdated  units  are  not 
replaced  by  more  efficient/effective  units. 

b.  Develop  New  Units 

New  developments  often  run  a  high  degree  of  risk 
which  could  result  in  a  late  delivery.  New  units  often  run 
up  the  cost  of  the  project. 

5.  3A12JL  pecision? 

Again  the  planners  were  required  to  make  judgemental 
decisions  about  performance/cost  trade-offs.  Since  new 
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units  usually  increased  both  performance  and  cost,  and 
existing  units  tended  to  reduce  project  cost,  the  planners 
had  to  select  the  appropriate  trade-offs. 

The  planners*  decision  to  use  existing  units  for 
MPDS  proved  to  be  a  wise  one  since  the  new  units  experienced 
a  lot  of  logistic  problems  [Ref.  62]. 
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